Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@app/src/main/java/com/runnect/runnect/presentation/discover/upload/DiscoverUploadActivity.kt`:
- Around line 118-122: The event is logging Param.DISTANCE_M as a String
(uploadCourse?.distance) which breaks numeric analytics; update the
Analytics.logEvent call in DiscoverUploadActivity
(EventName.ACTION_COURSE_UPLOAD_COMPLETE) to convert uploadCourse?.distance
(from DiscoverUploadCourse.distance) to a numeric type before sending — e.g.,
safely parse to Double or Int (using a safe parse that returns null on failure),
optionally round/format as needed, and pass that numeric value (or null) for
Param.DISTANCE_M so parsing errors don’t crash and numeric aggregations work
correctly.

In `@app/src/main/java/com/runnect/runnect/presentation/draw/DrawActivity.kt`:
- Around line 497-503: The Analytics.logEvent calls in DrawActivity are sending
viewModel.distanceSum (which is in kilometers) as Param.DISTANCE_M; update both
places where Analytics.logEvent uses Param.DISTANCE_M to convert kilometers to
meters (multiply distanceSum by 1000) before passing it, taking care to handle
the distanceSum value/type/nullability (e.g., use distanceSum.value or safe-call
and convert to an Int/Double as expected by Analytics). Locate the calls to
Analytics.logEvent in DrawActivity (the blocks that include Param.DISTANCE_M to
viewModel.distanceSum.value and the similar block later) and replace the
argument with the converted meter value.

In `@app/src/main/java/com/runnect/runnect/presentation/login/LoginActivity.kt`:
- Around line 111-116: The current logging in LoginActivity sends the
user-facing error string (it) as Param.ERROR_CODE to Analytics.logEvent; replace
this with a stable, bounded code or category by mapping the raw message to an
enum/constant (e.g., LoginErrorCode or a function
mapLoginErrorToCode(errorMessage): String). Update the block that computes
method and calls Analytics.logEvent (the code referencing socialLogin,
GoogleLogin, EventName.ACTION_LOGIN_FAIL and Param.ERROR_CODE) to call your
mapper and pass the mapped code/category instead of the raw `it`; if no mapping
is found, emit a generic fallback code like "UNKNOWN_LOGIN_ERROR". Ensure the
mapper is deterministic and does not forward user-visible text to analytics.

In `@app/src/main/java/com/runnect/runnect/presentation/run/RunActivity.kt`:
- Around line 101-105: The analytics calls pass km-valued fields directly into
meter-named params; update each callsite (e.g., the Analytics.logEvent call
using EventName.ACTION_RUN_START with Param.TARGET_DISTANCE_M and similar calls
around lines referenced) to normalize distance to meters before logging by
converting the km value (runCourseData?.distance or distanceSum) to meters
(distanceInMeters = (value ?: 0.0) * 1000) and pass that normalized value to
Param.TARGET_DISTANCE_M / Param.COURSE_DISTANCE_M; do this conversion once per
callsite and ensure the type matches the analytics API (Int/Long/Double) when
calling Analytics.logEvent.

In `@app/src/main/java/com/runnect/runnect/util/analytics/Analytics.kt`:
- Around line 42-58: The logEvent implementation accepts unsupported Bundle
types (Int, Float, Boolean) that Firebase Analytics may not recognize; update
the loop in Analytics.logEvent to normalize params to Firebase-supported types
by converting Int -> Long (use putLong), Float -> Double (use putDouble), and
Boolean -> Long (1L/0L) or String, while keeping String, Long, and Double as-is
before calling firebaseAnalytics?.logEvent; ensure keys like COURSE_ID,
RESULT_COUNT, IS_NEW_USER are therefore stored as Long/Double/String to be
reliably processed by Firebase.

---

Outside diff comments:
In
`@app/src/main/java/com/runnect/runnect/presentation/discover/search/DiscoverSearchActivity.kt`:
- Around line 151-154: The success handler currently rereads
binding.etDiscoverSearchTitle instead of using the submitted local keyword,
causing KEYWORD/RESULT_COUNT mismatches if the user edits the field while the
request is inflight; change the flow to carry the submitted keyword with the
request (e.g., pass the local keyword into viewModel.getCourseSearch or include
it in the success state/emitted result) and update the success handler to
log/use that submitted keyword rather than re-reading
binding.etDiscoverSearchTitle; update both occurrences (the call at
getCourseSearch(...) and the corresponding success handling code) so the logged
KEYWORD is the exact keyword that started the request.

In `@app/src/main/java/com/runnect/runnect/presentation/login/LoginActivity.kt`:
- Around line 76-83: At each click handler (cvGoogleLogin, cvKakaoLogin and the
other similar handlers at the other occurrences), capture the chosen provider
method into an immutable/local variable (e.g., requestedMethod) at click time
instead of relying on the mutable socialLogin field; set socialLogin as before,
then record requestedMethod = googleLogin.method / kakaoLogin.method (or set a
separate lastRequestedMethod property) and pass or reuse that stored immutable
value inside the signIn result callbacks (success/failure event recording) so
the recorded method reflects the request that started rather than the current
value of socialLogin when the callback runs.

In
`@app/src/main/java/com/runnect/runnect/presentation/storage/StorageScrapFragment.kt`:
- Around line 106-109: The VIEW_STORAGE_SCRAP event is currently emitted inside
the refresh success path (e.g., from binding.refreshLayout.setOnRefreshListener
-> getMyScrapCourses()), causing it to fire on refreshes and miss failed initial
loads; move the VIEW_STORAGE_SCRAP emission out of the data-load success
handlers and into the fragment visibility entry point (e.g., onResume or the
fragment's entry lifecycle method) so it records a screen view when the user
actually sees the fragment; leave COURSE_COUNT emission tied to the load/result
event produced by getMyScrapCourses() (and any handlers for
ScreenRefreshEvent.RefreshStorageScrap) so counts reflect successful
fetches—apply the same change to the other occurrences referenced around the
getMyScrapCourses() calls (lines noted 119–124 and 183–186).